When MS-DOS™ and UNIX™ were developed, utility programs were small and focused in order to manage the tasks of a computer. Computing power was limited compared to modern systems, so software applications were also limited accordingly in complexity and functionality. The utility programs could be combined together to collectively perform somewhat more complex limited tasks that such relatively primitive computers were capable of.
With the advent of visual programming and the web, applications grew in structure, functionality, and complexity. As computing power also increased, software development projects grew in an attempt to solve larger problems. Accordingly, applications were harder to develop and maintain in direct relationship to the size and complexity of the application. The architecture often appeared to resemble that of an old fashioned vacuum tube radio, with wires going everywhere. The general parts were present to carry out the various tasks, but growth necessitated more structure.
As technological progress continues to be made, software solutions are much more sophisticated (at least from an academic standpoint), with well-defined types. Attempts have been made to provide better organization. For instance, in the model-view-view model (MVVM) paradigm, view models, interfaces, and types are grouped together in an attempt to better organize the structures, which was recognized as a best practice in software development. The browser display is driven by the markup (i.e., Hypertext Markup Language (HTML)), which is affected by the JavaScript, which communicates with the web server, whose requests are trafficked through the controller, which calls the corresponding servers, which maps its data from a view model to a model, which is sent to the repository, which communicates with the database. Conversely, the database will respond to the repository, the repository will respond to service, the service will map the models back to the view models, the view model will be sent back to the controller, the controller will respond to the client request, and the JavaScript will read the message and update the model. This process can be seen in more detail in flow diagram 100 of FIG. 1.
Not all actions require this specific structure. Different actions have varying levels of complexity. While there have been some areas of increased efficiency, this is generally on the peripheral edges of software development, and the bulk of the workload still remains.
Manual programming of software tends to be verbose and redundant. Typically, it takes many lines of code for a software developer to describe tasks, and each line of code a developer writes introduces the possibility of errors. Furthermore, generally speaking, the more lines of code that are required, the more programming time that is required; the more programming time that is required, the larger the team that is required; the larger the team that is required, the more oversite that is required. Oversite often comes in the form of coding standards, code reviews, and increased testing. Budget overruns are a major problem in the industry. In short, programming large applications is complex, time-intensive, and expensive.
Projects that may take weeks to describe in requirements may take in excess of a year to implement with a team of developers. The code will vary drastically from one developer to another, despite attempts to adhere to coding standards, which come at great expense. The application needs to be tested extensively and many bugs must be resolved. Finally, after the application has been released, the costs of maintaining or extending the application remain high. Adding a single field to an existing table can take one day or more for a developer familiar with that project. Bringing new developers up to speed often takes months. Moreover, much reverse engineering of a website has to be performed by a skilled developer as knowledge is lost. Even more exasperating, these problems are not limited to the web, but exist almost everywhere in software development today.
In order to attempt to reduce the amount of time required for developing software applications, programs that automatically generate at least some of the code have been developed. However, current applications that automatically generate code still typically require many manual interrelations and rigid templating. Furthermore, code generation is not an answer to software development problems in and of itself. Rather, automatic code generation needs to be done in an appropriate manner in order to be effective.
Conventional development frameworks generally create monolithic, illegible, and rigid code that often has limited scope and breadth. For instance, the Microsoft™ Entity Framework does not provide any support for business rules that are outside of the data layer. Moreover, a large set of specialty knowledge must be maintained. Overriding or extending the generated code from conventional frameworks is problematic, and often impractical. Furthermore, conventional code generation tools have proven to be notoriously troublesome with respect to team integration.
Some end-to-end tools, such as Microsoft Access™, simplify the development of software applications, even for non-software developers. However, this ease of use often comes with a myriad of problems. These problems include limits on the number of users, security limitations, performance issues, and limits as to how software can be extended.
Accordingly, an improved software development tool and approach may be beneficial.